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NOTICE TO READERS 


Three COPs are defined in the parent Recommendation (Telecommand, Part 2: Data 
Routing Service, 1987). Only two of these (COP-O and COP-1) have been developed and 
specified to the level of detail needed for implementation. Detailed specifications for COP- 
0 and COP-1 are contained in the attached draft of the Recommendation. 


However your attention is called to the fact that only COP-1 has been simulated, tested, 
supported with VLSI chip sets for flight applications, supported with portable ground 
software, and selected for use on upcoming flight projects in both ESA and NASA. 


No flight users have been firmly identified for COP-O , nor does future use seem likely. 
Therefore, unless comments are received by the Secretariat from agencies requesting the 
retention of COP-O, the Committee plans to withdraw it at the next revision. 


COP-2 (Selective Repeat of Telecommand Frames) has not yet been developed to the level 
of detail necessary for implementation or for this specification. It is believed that theneeds 
of missions previously thought to be candidates for a selective repeat protocol at the Data 
Routin'* (Frame) level may be better served either by use of the standard COP-1 protocol or 
by a to-be-developed selective repeat protocol at the Data Management (Packet) level 
(Telecommand, Part 3) instead. Therefore, unless comments are received by the Secretariat 
from agencies requesting the retention of COP-2, the Committee plans to withdraw it at the 
next revision. If it is decided its development should continue but is not completed when 
Part 2.1 is ready for approval, it will appear as a "To Be Supplied" item and will not cause 
delay in approving the rest of the Recommendation. The Recommendation may be reissued 
in a later year to add the protocol when it is completed. 


Normally,. Red Books are accompanied by a request for official agency review and 
approval. The Committee believes that this Red Book is new in a relatively stable, mature 
state, since it has been developed in close coordination between ESA and NASA. In 
particular, the definition of COP-1 is essentially the same as that being adopted in the ESA 
Telecommand Standard. Nevertheless, because it is a highly complex and important 
Recommendation, the Committee believes the agencies should have an extended period to 
understand, validate and test the protocol in their own environment, if they desire, before 
approval. Therefore, only informal technical comments are solicited from the agencies 
during the next 6 months or so. Comments should be directed to the Telecommand 
Working Group Chair: Kathy Moyd, NASA/JPL, Mail'S top 301-280, 4800 Oak Grove 
Drive, Pasadena, CA 91109; 

FAX +1 818 354 9068; ^ ^ 

TFT .EM AIL: (C:USA,ADMD:TELEMAIL,PRMD:NASAMAIL,0:NASA,UN:KMOYD). 


It is not planned to materially change the specification (except for possible withdrawal of 
COP-O and/or COP-2 and transfer of some of the explanatory information to an updated 
Telecommand Green Book) unless the change is justified. It is expected that the final 
Recommendation will be up for official approval, most probably in time for finalization at 
the Spring 1992 Plenary meeting. 
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STATEMENT OF INTENT 

(WHEN THIS RECOMMENDATION IS FINALIZED, IT WILL CONTAIN THE 
FOLLOWING STATEMENT OF INTENT:) 

The Consultative Committee for Space Data Systems (CCSDS) is an Organization officially 
established by the management of member space Agencies. The Committee meets periodically to 
address data systems problems that are common to all participants, and to formulate sound 
technical solutions to these problems. Inasmuch as participation in the CCSDS is completely 
voluntary, the results of Committee actions are termed RECOMMENDATIONS and are not 
considered binding on any Agency. 

This RECOMMENDATION is issued by, and represents the consensus of, the CCSDS Plenary 
body. Agency endorsement of this RECOMMENDATION is entirely voluntary. Endorsement, 
however, indicates the following understandings: 

o Whenever an Agency establishes a CCSDS-related STANDARD, this STANDARD will be 
in accord with the relevant RECOMMENDATION. Establishing such a STANDARD does 
not preclude other provisions which an Agency may develop. 

o Whenever an Agency establishes a CCSDS-related STANDARD, the Agency will provide 
other CCSDS member Agencies with the following information: 

The STANDARD itself. 

The anticipated date of initial operational capability. 

The anticipated duration of operational service. 

o Specific service arrangements shall be made via memoranda of agreement. Neither this 

RECOMMENDATION nor any ensuing STANDARD is a substitute for a memorandum of 
agreement. 

than flVC yCarS fr ° m itS date of issuance ’ this Recommendation will be reviewed by the 
LLSDS to deteraiine whether it should: (1) remain in effect without change; (2) be changed to 
reflect the impact of new technologies, new requirements, or new directions; or, (3) be retired or 


Red Book Issue 4 


n 


January 1991 



CCSDS RECOMMENDATION FOR TELECOMMAND: COMMAND OPERATION PROCEDURES 


FOREWORD 


This document, which is a technical Recommendation prepared by the Consultative Committee for 
Space Data Systems (CCSDS), is intended for use by participating space Agencies in their 
development of space telecommand systems. 

This Recommendation allows the implementing organizations within each Agency to proceed 
coherently with the development of compatible Standards for the flight and ground systems that are 
within their cognizance. Agency Standards derived from this Recommendation may implement 
only a subset of the optional features allowed herein, or may incorporate features not addressed by 
the Recommendation. 

The Recommendation for TelecommandtPart 2: Data Routing Service (Reference [3]) defines the 
standard data structures and data communication procedures to be used by conventional missions 
within the intermediate telecommand system layers. The Command Operation Procedures form a 
subpart of the Data Routing Service and are described in Reference [3]. This Recommendation 
contains the definition of the Command Operations Procedures in the form of state tables at the 
level of detail necessary to allow cross support. It is assumed that the reader is familiar with the 
terminology and data structures defined in Reference [3]. 

Through the process of normal evolution, it is expected that expansion, deletion or modification to 
this document may occur. This Recommendation is therefore subject to CCSDS document 
management and change control procedures which are defined in Reference [1]. 
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1 INTRODUCTION 

1. 1 PURPOSE AND SCOPE 

This Recommendation contains the detailed specification of the logic required to carry out 
the Command Operations Procedures of the Transfer Layer. 

The Recommendation for Telecommand: Part 2, Data Routing Service, (Reference [3D 
contains the standard data structures and data communication procedures used by the 
intermediate telecommand system layers (the Transfer and Segmentation Layers). In 
particular, it contains a brief description of the Command Operations Procedures (COP) 
within the Transfer Layer. This Recommendation contains the detailed definition of the 
COPs in the form of state tables, along with definitions of the terms used. It is assumed that 
the reader of this document is familiar with the data structures and terminology of Part 2. 

In case of conflict between the description of the COPs in Part 2 (Reference [3]) and in this 
Recommendation, the definition in this Recommendation will take precedence. In particular, 
this document supersedes Section 4.3.3. 1 through 4.3.3.4 of Part 2. 

1.2 APPLICABILITY 

This Recommendation serves as a guideline for the development of compatible internal 
Agency standards in the field of spacecraft commanding. This Recommendation is not 
retroactive, nor does it commit any Agency to implement the recommended telecommand 
concepts at any future time. Nevertheless, all CCSDS Agencies accept the principle that all 
future implementations of telecommand which are used in cross-support situations will be 
based on this Recommendation. 

The CCSDS has developed a layered concept for future spacecraft telecommanding, which is 
summarized in Reference [5] and defined in the Telecommand Recommendations Part 1 : 
Channel Service (Reference [2]), Part 2: Data Routing Service (Reference [3]) and Part 3: 
Data Management Service (Reference [4]). Standard services are defined within each layer, 
and Agencies will be encouraged to develop corresponding facilities to provide these services 
in support of Projects. This Recommendation is applicable only to those Projects which are 
compatible with the Transfer Layer as defined in the Recommendation for Data Routing 
Service (Reference [3]). 

Where preferred options or mandatory capabilities are clearly indicated herein, the indicated 
sections of the specification must be implemented when this Recommendation is used as a 
basis for cross-support. Where optional subsets or capabilities are allowed or implied in this 
specification, implementation of these options or subsets is subject to specific bilateral cross- 
support agreements between the Agencies involved. 

The recommendations in this document are to be invoked through the normal standards 
programs of each member Agency, and are applicable to those missions for which cross- 
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support based on capabilities described in these recommendations is anticipated. 

No later than five years from its date of issue, this Recommendation should be reviewed by 
the CCSDS Agencies to determine whether it should: 1) remain in effect without change; 2) 
be changed to reflect the impact of new technologies, new requirements, or new directions; 
or 3) be retired or cancelled. 

1.3 STATE TABLE FORMAT 

This document contains the state tables for each of the TC COPs. For each FOP or FARM, 
the State Table shows the various "STATES" (columns) in which the process might be at a 
given time, and the "EVENTS" (rows) which cause "ACTIONS" and/or STATE changes. 
The ACTION and/or STATE change appropriate to the occurrence of a particular event, 
when the processes are in a particular STATE, is shown at the intersection of the respective 
row and column. STATE transitions are indicated by STATE NUMBERS in parenthesis; 
thus "(S2)" indicates "go to STATE number 2". See Figure 1.1. 



AFTER PERFORMING *SET COUNTER TO 1*G0 
TO STATE 3 AND WAIT FOR THE NEXT EVENT. 

FIGURE 1.1: State Table Format 

Note: The table describes the processing for one independent virtual channel. 
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1.4 OVERVIEW OF COPS 

1.4.1 COP-O 

COP-O is a closed-loop telecommanding protocol within which control of sequentiality is 
provided by the sending-end FOP rather than the receiving-end FARM. The FARM sends 
down a count of the valid Type A commands received on the Virtual Channel. In order to 
ensure the delivery of frames in order, with no omissions, the spacecraft must stop accepting 
Type A frames on all Virtual Channels using COP-O if an invalid frame is received or if there 
is a problem with the physical channel which might cause frames to be lost. In such a case, 
the Lockout Flag in the CLCW is set. The ground will then use the counter value in the 
CLCW to determine how many frames have been accepted and therefore from what point 
retransmission should occur. Because the end of a CLTU causes a decoder failure, all frames 
to be transmitted before any acknowledgements are received on the ground must be included 
in the same CLTU. The start of a new CLTU also unlocks FARM-0 on all Virtual Channels. 

Valid Type B frames (i.e., bypass frames) will always be accepted. There are no control 
commands (Type BC) for COP-O. 

1.4.2 COP-1 

COP-1 is a closed-loop telecommanding protocol which utilizes sequential ("go-back-n") 
retransmission techniques to correct TC Frames which were rejected by the spacecraft 
because of error. COP-1 allows Type-A TC Frames to be accepted by the spacecraft only if 
they are received in strict sequential order and their contents can be immediately passed on to 
the layer above. 

Within COP-1, controi of sequentiality is provided by the FARM instead of the FOP, and 
therefore frame sequence numbering is explicit. The Frame Sequence Number must be 
present in each frame, and Type-A frames must be transmitted by the FOP with their 
numbers arranged in strict upcounting order. If one or more frames are missed, 
retransmission is initiated either in response to a Retransmit Flag in the CLCW or a timeout 
on the ground. Window mechanisms on the ground and spacecraft prevent a new frame with 
the same sequence number as that of a missing frame from being accepted. 

Valid Type B frames (i.e., bypass frames) will always be accepted. 
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2 COP-O 

COP-O is a closed-loop telecommanding protocol within which control of sequentiality is 
provided by the sending-end Frame Operation Procedure (FOP) rather than the receiving-end 
Frame Acceptance and Reporting Mechanism (FARM); therefore numbering of frames by the 
FOP is unnecessary. The FRAME SEQUENCE NUMBER Field must be present in every TC 
Frame, but since it is unused by the FARM its contents are set by convention to value "all 
zeros". 

FOP-O accepts batches of user data in the form of Frame Data Units (FDU) from the layer 
above, formats each FDU into a TC Frame and passes the batch of frames to the lower layer 
for transmission within a single Command Link Transmission Unit (CLTU). The batches may 
range in size from 1 to 256 FDUs (i.e., the resulting CLTU may contain from 1 to 256 TC 
Frames.). The content of the Frame Data Unit will be a TC segment if the interfacing higher 
layer is the Segmentation Layer, one TC Packet 1 if the higher layer is the Packetization Layer 
or a user-defined data unit if the higher layer is neither of these. 

FARM-0 submits each received frame to the standard Frame Validation Check that is defined in 
Part 2, Section 4.3.2. Any Type-B frame which passes the validation check is distributed on 
its appropriate Virtual Channel and the FARM-B COUNTER is incremented. Any Type-A 
frame which passes the validation check is distributed on its appropriate Virtual Channel and 
the FARM-A COUNTER is incremented, unless the FARM is in the Lockout State. 

Any Type-A or Type-B frame which fails the Frame Validation Check shall be discarded, and 
FARM-0 shall immediately enter LOCKOUT to prevent the acceptance of further Type-A 
frames on ANY Virtual Channel. This is necessary since the FARM has no knowledge of the 
Type or Virtual Channel assignment of the erroneous frame; therefore all Virtual Channels must 
be locked out to preserve sequentiality. Any subsequent Type-B frame which passes the 
Frame Validation Check will be processed normally. The LOCKOUT mode for Type-A 
frames will remain in effect until it is cleared by reception of the start sequence at the beginning 
of a new CLTU. Receipt of a valid start sequence allows resumption of operation on all Virtual 
Channels. To avoid the inadvertent resetting of a Lockout condition, FOP-O must wait until all 
frames of a CLTU have been received and acknowledged before initiating a new CLTU. This 
send-and-wait technique makes COP-O inefficient in long delay or high data rate applications. 
It is designed primarily for low-rate commanding of earth-orbiting spacecraft without the use of 
data relay satellites. 

In the event of an observed LOCKOUT, FOP-O ceases the transmission of frames to the layer 
below, calculates the number of Type A frames which were accepted by the FARM prior to the 
failure (by subtracting the initial value of the FARM-A COUNTER from its current value) and 
"goes-back-n" to initiate a new CLTU, retransmitting the unacknowledged Type A frames from 
the point of failure. Retransmission is not provided for Type B frames. 

1 The current issue (Issue 1) of the CCSDS Recommendation for Telecommand, Part 2: Data Routing Service 
(Reference [3]) allows only one TC Packet per FDU. The technical experts have agreed in principle that 
multiple complete Packets should be allowed and this is expected to be incorporated in the next issue of 
Reference (31. 
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"goes-back-n" to initiate a new CLTU, retransmitting the unacknowledged Type A frames from 
the point of failure. Retransmission is not provided for Type B frames. 

Acceptance of a Type-A frame on a particular Virtual Channel by FARM-0 causes the 
following actions: 

A. The value of the FARM-A COUNTER shall increment by one, and 

B . The CLCW parameters for that Virtual Channel shall be updated. 

Receipt of a valid Type-B frame on a particular Virtual Channel by FARM-0 causes the 
following actions: 

C. The FARM-B COUNTER shall increment by one, and 

D. The CLCW parameters for that Virtual Channel shall be updated. 

Since any frame which fails a Frame Validation Check will cause FARM-0 to enter LOCKOUT 
and reject all subsequent Type-A frames REGARDLESS OF THEIR VIRTUAL CHANNEL, 
any error in any frame will effectively stop the entire flow of telecommands on all Virtual 
Channels which use COP-O until corrected. 

The COP-O protocol is described by means of state tables, one at each end for each Virtual 
Channel. The state table for FOP-O is given in Table 2.1; the state table for FARM-0 is given 
in Table 2.2. A description of how to read the tables is given in Section 1.3. 

2.1 STATES 

ACTIVE 

FOP in nominal status; ready to accept FDUs from upper layers and transmit them. 

AWAITIN G ACKNOWLEDGEMENT 

FOP is waiting for receipt of previously transmitted Type A frames to be confirmed by receipt 
of CLCWs. No additional frames can be transmitted. 

LOCKOUT 

An invalid frame has been received or a problem has occurred on the physical link. The FARM 
rejects all subsequent Type-A frames until reset by the start of a new CLTU. 

OPEN 

FARM is ready to accept frames. No anomalous conditions exist. 
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2.2 VARIABLES 

CLCW 

Command Link Control Word 
CLCW Flag 

The logical "OR" of all flags in the CLCW used by COP-O: NO-RF-AVAIL, NO-BIT-LOCK, 
LOCKOUT. 

CLTU 

Command Link Transmission Unit 
FARM-A Counter 

An 8-bit counter, reported in the CLCW, which increments once for every Type-A frame that is 
accepted by the FARM on a particular Virtual Channel. 

FARM-B Counter 

A 2-bit counter, reported in the CLCW, which increments once for every Type-B frame that is 
accepted by the FARM on a particular Virtual Channel. 

Lockout Flag 

The CLCW field that shows whether the receiving end is in the Lockout state. 

N 

Used as a "local variable" in the state tables to show that the number of frames discussed in an 
action is the same as the number of frames mentioned (as N) in an event; N has no significance 
outside the state tables. 

New Count 

The command counter (FARM-A COUNTER) value, and hence the NN(R) Value which 
should be reached after all frames of a COP-O CLTU have been received and accepted at the 
receiving end FARM. 

NfRI 

FARM-A COUNTER value reported in a CLCW. 
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NN(R1 

Latest value of N(R) recorded at the sending end FOP for a given channel. 

Sent Queue 

The FOP-maintained list of Type A frames which have been transmitted but not yet 
acknowledged. 

The meaning of "acknowledged" is: 

Each increment of the FARM-A counter acknowledges one Type-A frame in the current CLTU, 
in sequence, starting with the first. Thus if NN(RI) is the initial value of N(R) as recorded by 
the FOP before transmission of the CLTU, and NN(R) is the latest reported value, then the 
first NN(R) - NN(RI) frames of the CLTU have been acknowledged. 

Timer 

A mechanism for applying the TIMEOUT PARAMETER to assure that the Higher Layer is 
notified if successful receipt by the spacecraft has not been not verified within a reasonable 
time. 

Transmission Count 

The Transmission_Count is the number of times a frame has been transmitted or retransmitted. 
Transmission Limit 

The Transmission_Limit is the maximum number of times that a frame may be transmitted. 
This includes the first transmission and any subsequent retransmissions of the frame. 

2.3 ACTIONS 

Accept frame 

The FARM logic embodied in the state table has determined that a frame has passed the COP 
acceptance checks. The FARM should deliver the frame under consideration to the receiving 
end higher layer. 

Ales 

The FOP should inform the operator or supervising process that some non-nominal event has 
occurred. 
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Cancel Timer 

"Turn off a timer that would otherwise, upon expiration, signal that one or more frames failed 
to arrive and pass validation and acceptance checks at the receiving end. 

Dequeue 

Remove from the Sent Queue all frames which were acknowledged by the last CLCW, if any. 
Cancel the timer if all frames are removed from the Sent Queue. 

Discard 

A frame has failed to pass acceptance checks or the FARM is in a state which will not allow 
any Type-A-frames to be accepted. Do not accept the frame for delivery, i.e., discard the 
frame. 

Ignore 

Take no action; give no response; do not change state. 

Report 

Place the values of the parameters indicated into a CLCW for transmission to the sending end. 
Retransmit 

Remove a frame from the Sent Queue, determine if it has been transmitted the maximum 
number of times allowed, as specified by the value of Transmission_Limit and if not, pass the 
frame to the lower layer for transmission. If the frame is not rejected by the lower layer, place 
the frame back onto the Sent Queue pending acknowledgement and restart the Timer. 

If the frame is rejected by the lower layer, the FOP attempts to pass the frame for transmission 
until successful, or until the maximum number of attempts allowed is reached. 

If the FOP is unsuccessful in transmitting the frame within the number of attempts allowed, the 
FOP "alerts" a higher layer (or operator). 

Set NEW COUNT to NN(R') + N 

Set the value of this sending end parameter to the sum of the last-received value of the 
spacecraft command counter (FARM-A Counter), as recorded in NN(R), plus the number (N) 
of frames to be transmitted in the next CLTU. After transmission, and reception by the 
FARM, of that CLTU, the command counter, and therefore NN(R), should contain the value 
of NEW_COUNT. 
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Transmit 


Prepare an FDU for sending (via lower-layer services) to the receiving end. This includes 
formatting the FDUs as TC frames, setting the value of N(s) in the frame to 0 and starting or 
resetting a timer. The frame is then passed to the lower layer for transmission. If it is not 
rejected by the lower layer, the frame is placed on the Sent Queue pending acknowledgement 
and the Timer is started or restarted. If the frame is rejected by the lower layer service, the 
FOP attempts to pass the frame until successful or until the maximum number of attempts 
allowed is reached. 

Transmit User Data Type BD frame 

This is bypass commanding. The FDU will be formatted and transmitted as a type B command 
and thus will be accepted and delivered at the receiving end without regard to the value of the 
Lockout Flag. The frame will not be put on the Sent Queue and no retransmission will occur in 
case of a FARM-0 Lockout. 
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Table 2.1 FOP-O State Table 




STATE NAME 

ACTIVE 

AWAITING 

ACKNOWLEDGEMENT 



Main Feature of Slate 

Ready to transmit 

CLTU is being or has been 
transmitted 



State Number 

SI 

S2 






Event 

Category 

Event 

Conditions 

Event 

Number 



Report 

Valid CLCW 
with 
N(H)- 

NEW_COUNT 

Et 

Dequeue 

(SI) 

Dequeue 

(St) 


Valid CLCW 
with 
N(R)* 

NEW_COUNT 

CLCW_FL4G 
Transition 
0 to 0 or 
t to 1 or 
1 toO 

E 2 

Dequeue 

(SI) 

Dequeue 

<S2) 



CLCW_FLAG 
Transition 
0 to 1 

T ran$mission_ 
Count 
< 

Transmission __ 
Limit 

E3 

Ignore 

(SI) 

Dequeue; Initiate 
Retransmission ot All 
Frames Remaining on 

SENTQUEUE 

(S2) 




Transmission^ 

Count 

E4 

Alert 

Dequeue; Cancel Timer it 
Running: Alert 




Transmission_ 

Limit 


(SI) 

(S2) 

I 


Invalid COP-Q 
CLCW Arrives 


£5 

Ignore 

(SI) 

Aten 

<S2) 

Command 

Frame 

Transmission 

Request 

Events 

Receive 
Request from 
Upper 
Layer 

Receive 
Request to 
Sena 'N* 
FDUs ol User 
Data 

No Bypass 

£6 

Clear SENT QUEUE; 
NEW_COUNT:» NN (R) + N; 
Initiate Transmission oi 
All N Frames 
(S2) 

Reject 

(S2) 




Bypass 

E7 

Clear SENT_QUEUE; 
ImtiateTransmission 
ol User Data 
Type-BD Frames 
(SI) 

Reied 

(S2) 

Timeout 

Event 

TIMER Expires on Transmitted CLTU 

E8 

Ignore 

Alert 







(SI) 

(Si) 

Manage- 

ment 

Receive Set Transmission_Limit Directive 

E9 

Set Transmission Jjmu 
(SI) 

Set Transmission Lima 
<S2) 

Directive 

Events 

Receive Set Timer_Value Directive 

E10 

Set Tima revalue 
(SI) 

Set Timer_Value 
(S2) 


The "CLCW_FLAG Transition”, is a comparison of the ncwiy-rcccivcd CLCW with the last-rcccivcd CLCW 
and is given in the form of the value of the last-received CLCW_FLAG "to" the value of the ncwiy-rcccivcd 
CLCW_FLAG. ”0 to 0” and ”1 to 1” mean there has been no change since the previous report, "0 to 1” means 
first receipt of a CLCW in which at least one of the flags has been set to 1 (indicating a FARM problem) and "1 
to 0" means first receipt of a CLCW in which all previously-set flags have been reset to 0 (indicating the 
FARM is now ready to resume normal operation). 
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Table 2.2 FARM-0 State Table 


STATE NAME 

OPEN 

LOCKOUT 

Main Feature of State 

Normal state to accept 
frames 

Frames not accepted 

State Number 

SI 

S2 




Event 

Type 

Event 

Conditions 

Event 

Number 




Frame 

Events 

Valid User Data Type 
AD Frame 

El 


Accept Frame; Increment 
FARM A COUNTER 
(SI) 

Discard 

(S2) 


Valid User Data Type 
BD Frame Arrives 

E2 


Accept Frame; Increment 
FARM B COUNTER 
(SI) 

Accept Frame; Increment 
FARM B COUNTER 
(S2) 


Start of CLTU Signal 
Arrives from Lower 
Layer 

E3 


LOCKOUT_FLAG:-0; 

LOCKOUT_FLAG:-0; 





(SI) 

(SI) 


Invalid Frame, Loss of 
RF Lock, or Loss of 
Bit Lock Detected* 

E4 


LOCKOUT_FLAG>1 

(S2) 

Ignore 

(S2) 

Reporting 

Event 

CLCW Report Time 
Arrives 

E5 


Report COP-O 
CLCW Values 
(SI) 

Report COP-O 
CLCW Values 
(S2) 


‘NOTE: If the lower layer detects incoming frames that fail 
signaled to the FARM as Event E4 which drives the FARM 
maintain sequentiality. 


validation check, or loss of RF or bit lock, this is 
into lockout state. This is required by COP-O to 
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3 COP-1 

NOTE: In this section, although it may be mentioned that COP-1 handles "frames", these are 
actually partial frames made up of a TC Frame Data Unit (FDU) plus the Frame Header data 
generated by COP- 1 . The remainder of the Frame Header will be generated by the Lower 
Layer. The content of the Frame Data Unit will be the length of the FDU plus a) one TC 
segment if the interfacing Higher Layer is the Segmentation Layer or b) one TC Packet 1 if the 
Higher Layer is the Packetization Layer or c) a user-defined data unit if the Higher Layer is 
neither of these. 

COP-1 is just one of the functions performed within the Transfer Layer. It is the first function 
performed when an FDU is received by the Transfer Layer on the sending end and the last one 
performed before the FDU is delivered to the Higher Layer on the receiving end. For purposes 
of defining the interfaces to COP-1, the function following FOP-1 on the sending end will be 
called - "Frame Generation" and the one preceding FARM-1 on the receiving end will be called 
"Frame Validation Check". 

3.1 SERVICES AND PROTOCOLS 

3.1.1 SERVICES 

COP-1 provides two distinct services to the layer above. These services are: 

(a) Sequence-Controlled Service 

This service concerns two types of frames: 

- AD for frames carrying data from the layer above (TC FDUs) 

- BC for the two frames carrying protocol control information for configuring COP-1 
("Unlock" and "Set V(R)") 

In COP-1 the Sequence-controlled Service is based on an automatic request for retransmission 
(ARQ) procedure of the "Go-back-N" type with sequence-control mechanisms both on the 
ground and onboard the spacecraft and the necessary presence of a standard return data report 
in the telemetry downlink, the Command Link Control Word (CLCW). 

The Sequence-Controlled Service is initiated by means of four distinct "Initiate AD Service 
Directives" as shown in Table 3.1 (FOP-1 State Table). Two of these directives consist in 
transmitting one of the two control frames (BC). Each of he two control frames causes a well- 
defined action in FARM-1, which is then reflected in the CLCW. A timer is used to cause 


1 The current issue (Issue 1) of the CCSDS Recommendation for Telecommand, Part 2: Data Routing Service 
(Reference [3]) allows only one TC Packet per FDU. The technical experts have agreed in principle that 
multiple complete Packets should be allowed and this is expected to be incorporated in the next issue of 
Reference [31. 


Red Book Issue 4 


3-1 


January 1991 



CCSDS RECOMMENDATION FOR TELECOMMAND: COMMAND OPERATION PROCEDURES 


retransmission of the control frame if the expected response is not received, with a limit on the 
number of automatic retransmissions allowed before the Higher Layer is notified that there is a 
problem in initiating the AD Service. The other two directives allow the AD Service to be 
started without waiting for spacecraft action (although one requires receiving a good CLCW). 

Once COP-1 for a particular Virtual Channel has been initialized for an AD service, TC FDUs 
are inserted into frames and transmitted on that Virtual Channel in the order in which they are 
presented to COP-1. The retransmission mechanism ensures that: 

- No TC FDU is lost 

- No TC FDU is duplicated 

- No TC FDU is delivered out of sequence. 

The AD Service guarantees in-order delivery of TC FDUs on a single Virtual Channel. 
Because of the possibility of retransmission on only a single Virtual Channel, there is no 
guarantee that TC FDUs on separate Virtual Channels, each using an AD Service, will be 
delivered to the Higher Layer in the order initially transmitted. 

For the AD Frames, the automatic retransmission procedure makes use of several variables, the 
most notable being the Receiver_Frame_Sequence_Number, V(R); the 
Transmitter_Frame_Sequence_Number, V(S); the Next-Expected-Sequence-Number contained 
in the CLCW ,N(R); and the Frame-Sequence-Number in the TC Frame Header, N(S). (See 
Figure 3.1). These variables are defined in Section 3.2. 

GROUND SPACECRAFT 

TELECOMMAND 



CLCW IN 

TELEMETRY TRANSFER FRAME 


Figure 3.1 COP-1 Variables and Report Values 

The AD Service also offers, if required, a flow control mechanism ("Wait" system) which 
permits the higher layers onboard the spacecraft to signal that they are not able to cope with the 
incoming rate of uplink telecommand data. 


Red Book Issue 4 


3-2 


January 1991 



CCSDS RECOMMENDATION FOR TELECOMMAND: COMMAND OPERATION PROCEDURES 


For the BC Frames, the automatic retransmission procedure makes use of a very small number 
of variables, the most notable being the "Lockout" flag in the CLCW for the "Unlock" control 
frame, and the value "N(R)" in the CLCW for the "Set V(R)" control frame. 


(b) Expedited Service 

This service concerns the BD type of frames. BD frames are normally used only in exceptional 
operational circumstances, typically during spacecraft recovery operations. 

The service operates with one directive from the Higher Layer for each TC FDU ( Receive 
User Data Request from Higher Layer: BD Service" in the FOP-1 State Table). There is only 
one transmission for each BD frame (i.e., no retransmission). At the sending end, BD frames 
are given immediate access, as specified by the FOP-1 State Table. At the receiving end, the 
TC FDU carried by a BD frame will be passed to the Higher Layer immediately, independent 
of the value of the Lockout or Wait Flags. 

Note: Some implementations of FARM-1 may use the same output buffer for FDUs carried by 
either AD or BD frames in order to provide increased reliability through reduced complexity 
and lower resource consumption. In this case, when a BD frame is received, an FDU in the 
process of being transferred or "waiting" to be transferred will be erased, without any 
indication to the ground in the CLCW. An operational consequence is that for this 
implementation the sending end Higher Layer shall mandatorily and automatically terminate any 
ongoing AD Service before starting a BD Service on the same Virtual Channel. 

3.1.2 PROTOCOLS 

Each end of COP-1 is defined as a protocol machine which is described in a State Table. The 
description of the format used for the state tables in this document is given in Section 1 .3. 

The basic operation principle of the protocol machine is that it remains in a state until an event 
occurs. When an event occurs, it is analysed until it is tully identified and then the operations 
specified for the combination of that event and that state are executed. Finally the state variable 
is updated with the new state value specified for the combination. 

(i) At the Sending End: FOP-1 

The Frame Operation Procedure (FOP-1) protocol machine is described in Table 3-1. 

In the case of the arrival of a CLCW, some operations need to be performed before the FOP-1 
protocol for the Virtual Channel is invoked. In particular, not included in the FOP-1 State 
Table are operations such as checking: 

the "COP in Effect" 

the "Virtual Channel Identifier" 
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Included in the FOP- 1 State Tabie are the following operations: 


checking the value of the Lockout_Flag 
checking the value of N(R) 
checking the value of the Retransmit_Flag 
checking the value of the Wait_Flag 

(ii) At the Receiving End: FARM- 1 


The Frame Acceptance and Reporting Mechanism (FARM-1) protocol machine is described in 
Table 3-2). 


FARM-1 constantly generates a standard report, the CLCW, which is made available to the 
spacecraft telemetry system at regular intervals (Event El I in FARM-1 State Table). 


Not included in the FARM-1 State Table are operations concerning the validation of the frame 
When a valid frame arrives", this means that the Frame Validation Check process has placed a 
vi frame in the front end buffer of the FARM-1 protocol machine. This validation 

"Set U V(Rn nfyinS that a C ° mr01 iS ° ne ° f thg tW ° C0P ' 1 COntro1 frames ("Unlock" and 


Included in the FARM-1 State Table are the following operations: 

- checking the value of the Bypass Flag 

- checking the value of the Control Flag 

- checking the value of N(S) in .AD frames 

3.1.3 INTERLAYER INTERFACES 


,he h C0P - 1 . servic « and P r °‘°«>ls completely and clearly, it was necessary to 
define some of the characteristics of the interface between the COP and the Higher and Lower 
Layers. For example, a decision had to be made as to whether the Higher Layer delivers only 
one frame at a time to FOP-1 or may deliver a group of frames. A strategy for ensuring 
accountability of sequence-controlled frames all the way from the sending end Higher Layer 
through the spacecraft and back to the Higher Layer had to be established 


!*“ i?, a ' IZed that *“* are ° ther ways in which ,he ta«rfaces could be defined. In particular, if 
. y are implemented as part of a single system, their interfaces could be simplified It is 

“ ementors ,o ensure ,hat a " ° f ,he requi — <»* 

Communication interfaces are commonly defined in terms of "service primitives", which mav 
contain parameters. In this Section requests from a sending end higher layer for action by a 

::rr ref r d " d ~" ^ iayer «*■*£ - 

Reject Response, depending on whether or not it will attempt to execute the request The 
response does no. have to be issued immediaiely; the layer may wait until i, has Tetelined 
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whether it can attempt execution. For example, FOP-1 does not issue the Accept Response to 
the Higher Layer for a request to transmit an AD frame until it has actually passed the frame to 
the Lower Layer. This way the Higher Layer can use the Accept Response from one AD frame 
to initiate the request to transmit the next frame. 

For some directives, it is necessary to know whether the action was successfully completed. 
In these cases a Confirm Response is used in addition to the Accept Response. A Positive 
Confirm Response means that the action was successfully completed. A Negative Confirm 
Response means either that the action was not successfully completed or that it will not be 
possible to determine whether it was successfully completed. There may be a considerable 
time period between the Accept Response and the Confirm Response. For example, if the 
request is to transmit an AD Frame, the Confirm Response will not be issued until receipt of 
the frame on-board has been acknowledged by a CLCW (Positive Confirm) or it has been 
established that the sequence-controlled service has failed (Negative Confirm). 

The service primitive from a receiving end lower layer to a higher layer denoting that data has 
been received is called an "Indication". There are no specific responses defined in this Section 
from the receiving end higher layer to lower layer. An Indication is also used to provide status 
information from a sending end lower layer to higher layer. For example, an Alert Indication is 
used to notify the Higher Lover that COP-1 has failed, with a parameter giving the type of 
failure . 

3.2 INTERNAL VARIABLES 

This section describes the variables used by the COP-1 protocol machines at each end of the 
Transfer Layer link. The complete meaning of these variables can only be fully understood in 
conjunction with a careful reading of the COP-1 State Tables. It is these tables which, 
ultimately, contain the master definition of the COP-1 protocol. 

These variables are those which are defined as part of the protocol. Any implementation of the 
protocol machines is likely to have in addition many private, implementation-dependent 
variables. 

3.2.1 FOP-1 VARIABLES 

For each Virtual Channel the sending end protocol machine maintains the following variables: 


- State 

- Stored_Lockout_Flag 

- Stored_Wait_Flag 

- Stored_Retransmit_Flag 

- Transmitter_Frame_Sequence_Number (usually referred to as V(S)). 

- Wait_Queue 

- Sent_Queue 

- To_Be_Retransmitted_Flag 

- AD_Out_F!ag 

- BD_Out_Flag 
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- BC_Out_Flag 

- Expected_Acknowledgement_Frame_Sequence_Number (usually referred to as 

NN(R)) 

- Timer_Initial_Value (also known as Tl_Initial) 

- Transmission_Limit 

- Transmission_Count 

- FOP_Sliding_Window_Width (also known as K). 

- Timeout_Type (TT) 

- Suspend_State (SS) 

These are described in detail in the following sections. 

(i) State 

The state of FOP- 1 may be one of: 

- Active (SI) 

- Retransmit without Wait (S2) 

- Retransmit with Wait (S3) 

- Initialising without LC Frame (S4) 

- Initialising with BC Frame (S5) 

- Initial (S6) 

This variable represents the state of FOP-1 for the specific Virtual Channel. Each value of the 
State variable corresponds to a column in the FOP-1 State Table, Table 3.1. 

"Active" state (SI) is the normal state of the protocol machine when there are no recent errors 
on the link and no incidents have occurred leading to flow control problems. 

The protocol machine is in the "Retransmit without Wait" state (S2) while the Retransmit_Flag 
is "on" in the CLCW of the Virtual Channel but no other exceptional circumstances prevail. 

The protocol machine is in the "Retransmit with Wait" state (S3) while the Wait_Flag is "on" in 
the CLCW of the Virtual Channel (Some frames must always be retransmitted when the 
Wait_Flag is reset, since the Wait_Flag is set only when at least one frame has been 
discarded.). 

The protocol machine is in the "Initialising without BC Frame" state (S4) after receiving an 
"Initiate AD Service (with CLCW check) Directive" while in the "Initial" state. A successful 
CLCW check will result in a transition to SI. 

The protocol machine is in the "Initialising with BC Frame" state (S5) after receiving an 
"Initiate AD Service (with Unlock) Directive" or "Initiate AD Service (with Set V(R)) 
Directive" while in the "Initial" state with BC_Out = Ready. A successful transmission of the 
BC frame and a subsequent "clean" CLCW status will result in a transition to SI. 
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The protocol machine is in the "Initial" state (S6) whenever it is necessary to terminate an on 
going service (this happens when a "Terminate AD Service Directive" is received or when an 
"Exception", i.e. an event which causes an Alert, occurs). In principle, the Initial state is the 
first state entered by the protocol machine for a particular Virtual Channel. Although, in 
principle, all these Virtual Channels remain open during the life of the spacecraft, provision has 
to be made for interruptions of the physical link between the ground and the spacecraft and the 
operation of the one physical link from different ground stations. These considerations mean 
that it must be possible to start up a protocol machine on the ground more than once during the 
life of the spacecraft. 

In the Initial State TC FDUc may only be transmitted if they are BD frames. To start the 
sequence-controlled service, it is necessary to execute one of the four possible "Initiate AD 
Service Directives". If the directive is accepted and successfully executed, the protocol 
machine will be set to the "Active" state (SI). If the directive is not successfully executed (as 
would be the case if the transmission of an Unlock BC frame is not confirmed in the CLCW 
reports from the spacecraft after the maximum allowed number of timer-initiated 
retransmissions), FOP- 1 generates an Alert Indication and re-enters the Initial state. 

(ii) Stored_Lockout_Flag 

The Stored_Lockout_Flag contains the value of the Lockout_Flag from the previous CLCW on 
that Virtual Channel. 

(iii) Stored_Wait_Flag 

The Stored_Wait_Flag contains the value of the Wait_Flag from the previous CLCW on that 
Virtual Channel. 

(iv) Stored_Retransmit_Flag 

The Stored_Retransmit_Flag contains the value of the Retransmit_Flag from the previous 
CLCW on that Virtual Channel. 

(v) Transmitter_Frame_Sequence_Number, V(S) 

The Transmitter_Frame_Sequence_Number, V(S), contains the value of the Frame_Sequence 
_Number, N(S), to be put in the Transfer Frame Header of the next type AD frame to be 
transmitted. 

(vi) . Wait_Queue 

When Type AD TC FDUs are received from the Higher Layer they are held in the Wait_Queue 
until they can be accepted by the Transfer Layer. The Wait_Queue has a maximum capacity of 
one TC FDU. 
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The Wait_Queue and Accept response to Request to Transfer FDU form the primary 
mechanism by which flow control as seen by the higher Layer is governed. When an FDU is 
on the Wait.Queue, this means that the Higher Layer has not yet received an Accept response 
for the corresponding Request to Transfer FDU. 

(vii) To_Be_Retransmitted_Flag 

If retransmissions of the Sent_Queue are to be done because one or more frames were not 
acknowledged within the time allowed or were negatively acknowledged by a CLCW with the 
Retransmit Hag set , it is not reasonable to shut out all other FOP activity until the last frame on 
the Sent_Queue has been accepted by the Lower Layer (especially since the Lower Layer uses 
the Accept response as its flow control mechanism). During that possibly extended time other 
events may occur, such as the arrival of a CLCW, which must be processed. To handle this 
situation, each frame on the Sent.Queue carries a To_Be_Retransmitted Flag to distinguish a 
rame that has been transmitted (or retransmitted) and is awaiting acknowledgement (Flag reset) 
from one that must be retransmitted (Flag set). Upon receipt of an Accept response from the 

ower Layer, these flags will be used to determine which frame on the Sent_Queue if any to 
retransmit next. . J ' 


(viii) AD_Out_, BC_Out_ and BD_Out_Hags 

FOP-1 records whether or not a Transmit Request for Frame is outstanding for each of the 
three types of frames: AD, BC and BD. There are therefore three variables: 

-AD_Out_Flag (for AD frames) 

-BC_Out_Flag (for BC frames) 

-BD_Out_Hag (for BD frames). 

These may take one of two values: 


-Ready 

-Not_Ready 


Jf 0 /' 1 ^* ues aT J nsmit Request for Frame, it sets the appropriate "Out" variable to 
Not.Ready^ When the Transmit Request is accepted by the Lower Layer, FOP-1 sets the 
variable to Ready. 


(ix) Sent_Queue 


Sent-Queue is a virtual channel data structure in which the master copy of all type AD and 
BC frames on a Virtual Channel is held between the time a copy of the frame is first passed to 
the Lower Layers for transmission and the time the Transfer Layer has finished processing the 
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The Transfer layer has finished processing a type AD or BC frame when: 

-it receives (via the CLCW) a positive acknowledgement of receipt of the frame 
(perhaps after retransmission) 

-an event causes the Transfer layer to purge the Sent_Queue (i.e. an Exception or a 
"Terminate AD Service Directive"). 

Once the processing is finished, the master copy of the frame is removed from the queue and 
discarded and the (successful or not successful) transfer of the FDU is reported to the Higher 
Layer by means of a Confirm Response (Positive or Negative). 

(x) Expected_Acknowledgement_Frame_Sequence_Number (NN(R)) 

The Expected_Acknowledgement_Frame_Sequence_Number, NN(R), contains the value of 
N(R) from the previous CLCW on that Virtual Channel. NN(R)-1 is the value of the sequence 
number of the latest type AD frame which FOP-1 can guarantee has arrived safely. Because of 
the loop delay in the communications link, this value may lag behind the value of the onboard 
Receiver_Frame_Sequence_Number, V (R). 

(xi) Timer_Initial_Value (Tl_Initial) 

Whenever a type AD or BC frame is transmitted, the Timer is started or restarted. 

If a frame is lost on the physical link, no positive acknowledgement for that frame will be seen 
in the CLCW. If no later type AD or BC frame were transmitted on that Virtual Channel, there 
would be no way for FOP-1 to discover that the frame had not arrived. Therefore each Virtual 
Channel has a Timer which is started whenever a frame is transmitted or retransmitted. If an 
acknowledgement is seen for the frame, and no subsequent frame has been transmitted, then 
the timer is cancelled. If the Timer expires and the FOP Transmission_Count has not reached 
the FOP_Transmission_Limit (see following variables), it causes an event which initiates 
recovery action in the FOP-1 protocol machine. 

The Timer is not used when a type BD frame is transmitted. 

The value to which the Timer is set when it is started or restarted is referred to as Tl_Initial and 
may be changed using the Set Tl_Initial Directive. 

For normal operation, the smallest value of Tl_Initial shall be the sum of the following delays 
for a given Virtual Channel: 

- ground processing time of the layers below FOP-1. 

- time required to transmit a maximum-length frame (including the bits needed for the 
CLTU and coding) as a serial bit stream. 
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- uplink propagation time (one-way light time, including relay satellite path). 

- onboard processing time of the layers below FARM-1. 

- worst-case time required to sample and encode FARM-1 status data as a CLCW in the 
telemetry Transfer Frame. 

- time required to transmit a telemetry Transfer Frame. 

- downlink propagation time (one-way light time, including relay satellite path). 

- ground processing time to extract the CLCW from the telemetry Transfer Frame and to 
deliver it to FOP- 1. 


Note: a smaller value of Tl_Initial may be useful for deep space commanding with long 
round-tnp light times. It could be used to force retransmission of the entire Sent_Queue a 
specified number of times prior to receipt of any acknowledgement CLCWs. Assuming 
imeout_Type is set to 1 (see below), FOP-1 would be suspended once the maximum number 
ot transmissions were made. Its operation could then be resumed by the Higher Layer to 
process the acknowledgement CLCWs. In addition, a small value of Tl_Initial could be used 
to a low the Set V(R) command to be sent without having to verify its acceptance via a CLCW 
e ore sending the AD frames. In this case the Higher Layer would be alerted once the allowed 
number of transmissions of the Set V(R) were made and it could then issue an "Initiate AD 
Service (without CLCW Check)" Directive. 

(xii) Transmission Count Variables 

When a Type AD or BC frame is lost, the normal recovery procedure is to retransmit it If 
however there is a serious problem on the underlying physical link, no amount of 

retransmissions will permit an acknowledgement for the frame to appear in the CLCW for the 
v irtuai Channel. 


If nothing were done, there would be no way for COP-1 to detect the error. Therefore all 
FDUs containing user data passed from the ground Higher Layer (as well as all directives from 
the Control Authority in the Higher Layers) have associated with them, at least implicitly, a 
limit to the number of times the corresponding frame is to be transmitted. 

In order to keep from declaring that the link has failed when it is in fact getting frames into the 
spacecraft the transmission count limit applies only to the first frame on the Sent.Queue 
Once that frame is acknowledged, the count is reset, even though the remaining frames on the 
ent_Queue have been transmitted, possibly more than once. The effect is that the 
transmission count can be considered to be associated with the Sent.Queue, rather than with 
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Three FOP-1 variables are used for controlling the retransmissions. 

(a) Transmission_Limit 

The Transmission_Limit holds a value which represents the maximum number of times the first 
frame on the Sent_Queue may be transmitted. This includes the first "transmission" and any 
subsequent "retransmissions" of the frame. 

The value of the Transmission_Limit may be changed using the Set Transmission_Limit 
Directive. 

(b) Timeout_Type (TT) 

The Timeout_Type variable is referred to as TT. It may take one of two values, 0 or 1. It 
specifies the action to be performed when both the Timer expires and the FOP 
Transmission_Count (see next variable) has reached the FOP TransmissionJLimit. 

(c) Transmission_Count 

There are two different sorts of events which may cause FOP-1 to initiate retransmission of 
either a BC frame or one or more AD frames: 

* A CLCW arrives which negatively acknowledges a frame (Retransmit_Flag = 1). 

* The Timer expires before a CLCW positively acknowledging the last frame on the 
Sent_Queue has been received. 

Whenever a CLCW arrives which negatively acknowledges a frame, FOP-1 checks whether 
the value of the Transmission_Count has reached the value of the Transmission_Limit. If it 
has not, FOP-1 increments the count and initiates retransmission of the frames on the 
Sent_Queue. If it has, FOP- 1 generates an Alert Indication. 

Whenever the Timer expires before a CLCW positively acknowledging the last frame on the 
Sent_Queue has been received, FOP-1 checks whether the value of the Transmission_Count 
has reached the value of the Transmission_Limit. If it has not, FOP-1 increments the count 
and initiates retransmission of the frames on the Sent_Queue. If it has, FOP-1 selects one of 
two types of possible actions depending on the value of the Timeout_Type, TT: 

* if TT = 0, FOP- 1 generates an Alert Indication. 

* if TT = 1, FOP-1 suspends the AD Service, which may be resumed later if so required 
(see definitions of Suspend_State variable, SS, and Resume AD Service Directive). 
This feature is used, typically, for deep space commanding. 

Whenever one or more frames are acknowledged and therefore removed from the Sent_Queue, 
the Transmission_Count is reset to 1. The Transmission_Count is also set to 1 when FOP-1 
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prepares an AD or BC frame for transmission and the Sent_Queue was previously empty. All 
these actions are defined in detail in Section 3.5, Actions. 

For the Expedited Service (BD), there is no Transmission_Count variable, because each BD 
frame is only transmitted once. 

(xiii) Suspend_State (SS) 

The Suspend_State variable is referred to as SS. It may take one of five values, from 0 to 4. It 
records the State that FOP-1 was in when the AD Service was suspended (as described in 
paragraph (xii) above). This is the State to which FOP-1 will return should the AD Service be 
resumed. If SS=0, the AD Service is deemed not suspended. 

(xiv) FOP_Sliding_Window_Width (K) 

The value to which the FOP_Sliding_Window_Width is set is referred to as "K" and may be 
changed using the Set FOP_Sliding_Window_Width Directive. 

The FOP Sliding Window is a mechanism which limits the number of Transfer Frames which 
can be transmitted ahead of the last acknowledged frame, i.e. before a telemetered CLCW 
report is received which updates the status of acknowledged frames. This is to prevent sending 
a new frame with the same sequence number as a rejected frame. 

The value "K" shall be set to a value between the following limits: 



where PW is the FARM_Positive_Window_Width as defined in Section 3.2.2, FARM-1 
Variables, paragraph (vii) 

3.2.2 FARM-1 VARIABLES 

For each Virtual Channel the receiving end protocol machine maintains the following variables: 

- State 

- Lockout_Flag 

- Wait_Flag 

- Retransmit_Flag 

- Receiver_Frame_Sequence_Number (usually referred to as V(R)) 

- FARM-B_Counter 
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- FARM_Sliding_Window_Width (also known as W) 

- FARM_Positive_Window_Width (also known as PW) 

- FARM_Negative_Window_Width (also known as NW) 

- Buffer Administration Variables 

Finally each Virtual Channel must have available some storage for use as buffers. This implies 
the existence of data structures for administering the buffers. 

These variables are described in detail in the following sections. 

(i) State 

The State may be one of: 

- Open (SI) 

- Wait (S2) 

- Lockout (S3) 

This variable represents the state of FARM- 1. Each value of the State variable corresponds to a 
column in the FARM-1 State Table, Table 3.2. 

In Open State, the protocol machine accepts in-sequence frames and passes them to the Higher 
Layer. 

In Wait State, there is no buffer space available in which to place any further received Type AD 
user data frames. The protocol machine enters the Wait State when it has received a Type A 
TC FDU, but is unable to deliver it to the Higher Layer. It leaves the Wait State upon receipt 
of a buffer release signal from the Higher Layer. 

Lockout State is entered if the protocol machine receives a frame with sequence number N(S) 
outside the range expected if FOP-1 is operating correctly. It is a safe state in that no user data 
will be accepted or transferred to the Higher Layer when in the Lockout State (unless bypass is 
used). The protocol machine leaves the Lockout State upon receipt of an Unlock control 
command. 

(ii) Lockout_Flag 

The Lockout_Flag is set to "1" whenever the protocol machine is in Lockout State; otherwise, 
it is "0". When the CLCW is to be encoded for a particular Virtual Channel, the value of this 
flag is read out into the CLCW of that Virtual Channel. 

(iii) Wait_Flag 

The Wait Flag is set to "1" whenever the protocol machine is in Wait State; otherwise, it is "0". 
When the CLCW is to be encoded for a particular Virtual Channel, the value of this flag is read 
out into the CLCW of that Virtual Channel. 
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(iv) Retransmit_Flag 


The Retransmit_Flag is set to "1" whenever the protocol machine knows that a type AD frame 
has been lost in transmission or has been discarded because there was no buffer space 
available; otherwise, it is 0". When the CLCW is to be encoded for a particular Virtual 
Channel, the value of this flag is read out into the CLCW of that Virtual Channel. The 
appearance of the set condition of the flag on the ground forms a negative acknowledgement of 
all previously transmitted frames with a N(S) equal to or greater than N(R). The Flag will be 
reset to "0" upon successful receipt of a frame with N(S) = N(R), receipt of a Set V(R) control 
command (unless in Lockout State) or receipt of an Unlock control command. 

(v) FARM-B_Counter 

This variable is incremented whenever a valid BD or BC frame arrives. The value of this 
variable is read out into the CLCW but is not used by the COP-1 protocol machines at either 
end of the link. The counter is intended for use by layers above the Transfer Layer to offer a 
minimal facility for a Higher Layer error control loop when using bypass mode. 

How the Higher Layers access the CLCW to obtain the value of the FARM-B_Counter is not 
defined in this specification. It is implementation dependent. 

(vi) Receiver_Frame_Sequence_Number V(R) 

This variable records the value of the N(S) expected to be seen in the next type AD frame on 
this Virtual Channel. 

(vii) FARM Sliding Window Variables 

The purpose of the COP-1 Sliding Windows is to protect FARM-1 against the unauthorized 
(uncontrolled) transfer of a sequence of frames such that the Frame Sequence Number, N(S), 
of one or more of these frames will exceed the current value of the 
Receiver_Frame_Sequence_Number, V(R), by at least 256. 

The purpose of the FOP Sliding Window (defined in terms of its width "K” in Section 3.2.1, 
FOP-1 Variables, Paragraph (xiv) is to limit the number of frames which can be transmitted 
safely ahead of the last acknowledged frame. The purpose of the FARM Sliding Window is to 
protect FARM-1 against any malfunction or erroneous set-up of FOP-1. 

The FARM Sliding Window is defined in terms of three variables: 

♦its total width, referred to as "W" 

♦the width of its positive part, referred to as "PW" 

♦the width of its negative part, referred to as "NW" 
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The three variables are specified in the next subparagraphs, as well as the main related actions. 
Figure 3.2 illustrates the FARM Sliding Window concept with its different sections and 
actions. 

(viii) FARM_Sliding_Window_Width (W) 

The FARM_Sliding_Window_Width is referred to as "W" and gives the range over which the 
Frame Sequence Numbers of received AD frames may vary without lockout occurring. 

The value "W” shall be set to a value between the following limits: 


2 <= W <= 254 


where W is always an EVEN integer. 

Unless otherwise specified, the value "W" shall be fixed for the entire duration of the mission. 
In particular, there are no COP-1 control commands for changing the value. 

(ix) FARM_Positive_Window_Width (PW) and FARM_Negative_Window_Width (NW) 
As shown in Figure 3.2: 

*The FARM Positive Window area starts with V(R) and extends PW frames in the 
positive direction. 

*The FARM Negative Window area starts at V(R) - 1 (the number of the last accepted 
frame) and extends NW frames in the negative direction. 


The widths of both parts of the FARM Sliding Window are specified as follows: 


PW = NW = W/2 
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A Frame Sequence Number, N(S), falls outside the FARM Sliding Window (e.g., into the 
lockout area of width 256 -W) when: 



When the frame is in the lockout area, FARM-1 will discard the frame, go into the Lockout 
State and set the Lockout Flag. 

When N(S) falls inside the FARM Sliding Window, one of the following three cases will 
occur: 


♦FIRST CASE 


N(S) = V(R) 


The frame is in the positive window and contains the expected Frame Sequence Number; the 
frame is accepted. This is the case when COP-1 is operating correctly and no previous frames 
have been lost or discarded. It is also the case when retransmitted frames are received after 
they have been lost or discarded. 

♦SECOND CASE 



The frame is in the positive window and does not contain the expected Frame Sequence 
Number, the frame is discarded and the Retransmit Flag is set, if it has not already been set. 
This case occurs when a previous frame has been lost or discarded and retransmission has not 
yet started. 
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Figure 3.2 FARM Sliding Window Concept 
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*THIRD CASE 



The frame is in the negative window and is discarded without any other action being taken. 
This case occurs if frames are retransmitted even though they have been accepted. This could 
happen, for example, if the FOP Tl_Initial has been set to a too-small value or if there is a 
telemetry outage. It may occur during operations using the forced-retransmission mechanism 
for deep space missions. 

NOTE:Certain missions may require only a single transmission of a sequence of AD Frames in 
one COP-1 session (Transmission_Limit =1), whether in the Suspend/Resume mode of 
operation or not. For such missions, and in such a mode it is permitted to set PW > NW, 
with, ultimately, NW = 0 and PW = W, where W can be any integer between 1 and 256 
inclusive. Thus: 



Whatever the value of PW, the value of the FOP_Sliding_Window_Width, K, may never 
exceed 255. 

(x) Buffer Administration Variables 

The receiving end of the Transfer Layer requires storage to process the frames arriving from 
the ground and to contain data to be passed to the Higher Layer. 

The actual storage allocation strategy is implementation dependent. However the way 
FARM-1 is defined in the state tables implies that certain aspects of this strategy are not 
implementation dependent. These are described here. 
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The FARM-1 state tables imply the existence of the following FARM-1 buffers: 

-one "front end" buffer to contain one maximum length frame for use while the Transfer 
Layer Frame Validation Checks are performed. 

-at least one "back end" buffer to contain the data (TC FDUs) to be passed to the Higher 
Layer. 

If only one "back end" buffer is provided, the main requirement is that the data contained in 
incoming BD frames have priority : if the back end buffer still contains data, these data shall be 
erased and the buffer made available to the incoming (BD) FDU. (See Note in Section 3.1.1, 
Paragraph (b).) 

3.3 COP-1 INTERFACE TO HIGHER LAYER 
3.3.1 SENDING END 

In addition to the normal data transfer interfaces to the FOP-1 protocol machine, a number of 
management functions may be performed by the Higher Layers. These may be regarded as 
either a special set of commands from the Higher Layer (with the Higher Layer description 
modified to include them) or they may be regarded as a separate higher interface to the Transfer 
Layer. It is also expected that additional status information will be passed from FOP-1 to the 
Higher Layer for use in performance monitoring and problem diagnosis. 

In order to describe the way the Transfer Layer responds to requests from the Higher Layers, 
we consider the Higher Layer to Transfer Layer interface as two separate interfaces: 

- a Sequence-Controlled Service Interface 

- an Expedited Service Interface 

The Sequence-Controlled Service (short name: AD Service) consists essentially of guaranteeing 
the successful transfer of TC FDUs by means of AD frames. However, the two BC frames are 
also generated and serviced when the proper Directive is sent. 

The Expedited Service (short name: BD Service) consists essentially of transmitting each TC 
FDU in one BD frame. 

The following service primitives, described in detail in the next subsections, are defined for 
each Service Interface: 

o Sequence-Controlled Service Interface: 

- many different Directives 

- Accept Response to Directive 

- Reject Response to Directive 

- Positive Confirm Response to Directive 
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- Negative Confirm Response to Directive 

- Alert Indication 

- Request to Transfer FDU 

- Accept Response to Request to Transfer FDU 

- Reject Response to Request to Transfer FDU 

- Positive Confirm Response to Request to Transfer FDU 

- Negative Confirm Response to Request to Transfer FDU 

o Expedited Service Interface 

- Request to Transfer FDU 

- Accept Response to Request to Transfer FDU 

(a) Sequence-Controlled Service Management Interface 

The Sequence-Controlled Service Management Interface is the service access point for 
exchanging information between the management functions of the Higher Layers and the 
Transfer Layer. 

This access point serves to permit the Higher Layer to request services from the Transfer Layer 
in connection with managing a Virtual Channel. These service requests are referred to in this 
document as Directives. 

In addition, the access point serves to permit the Transfer Layer to report the status of a Virtual 
Channel to the Higher Layers. In particular, exception conditions are signalled by means of a 
service primitive called an Alert Indication. 

The service primitives defined on this interface are described hereafter. 

NOTE: Other management information, such as spacecraft identification, TC codeblock 
length, uplink bit rate, etc., which must be provided by the Higher Layers, is not included here 
for the sake of clarity: their detailed implementation not only reflects the layered nature of the 
telecommand system, but also the operational philosophy of the network facilities, which is 
outside the scope of this Recommendation. 

1) - Directives 

Service Requests from the Higher Layer management function are referred to here as 
"directives”. These are: 

- 4 Initiate AD Service Directives 

- 1 Terminate AD Service Directive 
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- 1 Resume AD Service Directive 

- 5 FOP-1 Setup Directives 

Furthermore, any other Directive will be rejected and reported as 


- an "Invalid" Directive 


The 12 directives correspond to Events E23 through E40 in the FOP-1 State Table. They are: 

- Initiate AD Service (without CLCW check) Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 

- Initiate AD Service (with CLCW check) Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 

- Initiate AD Service (with Unlock) Directive 
Parameters: 

- directive identifier 

- Virtual Channel identifier 

- Initiate AD Service (with Set V(R)) Directive 

Parameters: 

- V*(R), the new value for V(R) 

- directive identifier 

- Virtual Channel identifier 

- Terminate AD Service Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 

-Resume AD Service 
Parameters: 

- directive identifier 

- Virtual Channel identifier 

- Set V(S) to V*(S) Directive 

Parameters: 

- V*(S), the new value for V(S) 

- directive identifier 

- Virtual Channel identifier 
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- Set FOP_Sliding_Window_Width Directive 

Parameters: 

- new value for width of FOP Sliding Window (K) 

- directive identifier 

- Virtual Channel identifier 

- Set Tl_Initial Directive 

Parameters: 

- new value for Timer_Initial_Value (Tl_Initial) 

- directive identifier 

- Virtual Channel identifier 

- Set Transmission_Limit Directive 
Parameters: 

- new value for Transmission JLimit 

- directive identifier 

- Virtual Channel identifier 

- Set Timeout_Type Directive 

Parameters: 

- new value for Timeout_Type (TT) 

- directive identifier 

- Virtual Channel identifier 

- Invalid Directive 

Parameters: 

- any invalid directive identifier 

- Virtual Channel identifier 

2) - Responses 

Asynchronously from the directive, the Transfer Layer returns a Response to Directive. This 
indicates whether FOP-1 will try to execute the directive. This may be one of: 

- Accept Response to Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 

- Reject Response to Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 
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After each Accept Response to Directive, but asynchronously from that Response, the Transfer 
Layer signals to the Higher Layer a Confirm Response referring to the directive. This indicates 
whether or not COP-1 (including FARM-1 for directives requiring receiving end action) was 
able to complete the execution of the directive. This may be one of: 

- Positive Confirm Response to Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 

- Negative Confirm Response to Directive 

Parameters: 

- directive identifier 

- Virtual Channel identifier 

The Negative Confirm Response to Directive service primitive does not carry a parameter 
giving the reason for the failure to confirm performance of the service requested by the 
Directive. However, whenever a condition is detected which might give rise to Negative 
Confirm Response to Directive service primitives, an Alert Indication is signalled from the 
Transfer Layer to the Higher Layer. 

3) - Alert Indications 

If an unrecoverable error occurs on the link, then the Transfer Layer passes an indication to the 
Higher Layer. 

- Alert indication 

Parameters: 

- reason for alert 

- Virtual Channel identifier 


This alert indication serves as notice of the termination of the Sequence-Controlled Service 
guarantee. 


The reason for an Alert Indication may be one of the following: 


- Allowed number of transmissions exhausted for an AD frame: Alert [limit]. (Note: 
This Alert Indication cannot occur if the timer has expired and the Timeout_Type 
variable is set to T). 

- Allowed number of transmissions exhausted for a BC frame derived from a directive 
(e.g. Initiate AD Service Directive with "Unlock” or with "Set V(R)"): Alert [limit], 

- Lockout detected: Alert [lockout]. 
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- CLCW with Retransmit Flag = O and N(R) = NN(R) has arrived when last CLCW 
seen previously showed Retransmit Flag = 1: Alertfsynch]. 

- All frames sent are acknowledged but Retransmit_Flag is "on": Alertfsynch]. 

- An attempt to acknowledge frames is made during the initializing phase corresponding 
to State (S4): Alert[synch]. 

- CLCW with invalid N(R) has arrived: Alert[NN(R)]. 

- CLCW with Wait Flag = 1 and Retransmit Flag = 0 has arrived: Alert[CLCW]. 

- CLCW with invalid pattern of bits has arrived: Alert[CLCW]. 

- FOP-1 and Lower Layer are out of synchronisation (Lower Layer rejects frame even 
though appropriate OUT flag is set to Ready): Alert [LLEF]. 

- A "Terminate AD Service Directive" has arrived: Alert[term]. 

The Alert Indication implies the end of the Sequence-Controlled Service guarantee on the error 
free transfer of data to the spacecraft. Higher Layer recovery actions are necessary to try to 
ensure that data are not lost, duplicated or erroneous. 

The Alert Indications relating to the transmission count may be as a result of a break in the 
underlying physical link and may therefore be caused by problems outside the Transfer Layer. 

All other Alert Indications report the breakdown of the Transfer Layer protocol. This means 
that some part of the system is not operating to specification (therefore, reports already received 
by the layers above FOP-1 are likely to have been incorrect). 

In particular, an Alert Indication carries the Virtual Channel identifier corresponding to the 
FOP-1 in which the error condition was detected; but, given that the protocol mechanism has 
broken down, it is possible that the Virtual Channel identifier is incorrect. A single failure may 
cause the same or different Alert Indications on more than one Virtual Channel. 

A Lockout Detected Alert will not occur if the Lockout was detected and reported by an earlier 
Alert Indication and it has not changed since that indication. 

4) - Suspend Indication 

By setting Timeout_Type to "1" and setting a small value of Tl_Initial it is possible to cause 
FOP-1 to transmit a sequence of Type AD frames a specified number of times and then 
suspend its operation, without clearing its buffers. The Suspend Indication is used to notify 
the Higher Layer that the transmissions have been completed and that the operation has been 
suspended. A subsequent Resume directive will then cause FOP-1 to resume operation in the 
same state it was in when it was suspended. 


Red Book Issue 4 


3-24 


January 1991 



CCSDS RECOMMENDATION FOR TELECOMMAND: COMMAND OPERATION PROCEDURES 


(b) Sequence-Controlled Service FDU Transfer Interface 

Data transferred through this interface enjoy the protection of all the Transfer Layer facilities 
and are covered by the guarantee to deliver data without error, in order and without omission or 
duplication to the spacecraft. 

Only one operation may be performed by the Higher Layer on the interface. This is to present 
to the Transfer Layer: 

- Request to Transfer FDU (AD Service) 

Parameters: 

-FDU 

- request identifier 

- Virtual Channel identifier. 

After each request, perhaps immediately, perhaps after a delay, the Transfer Layer returns to 
the Higher Layer a Response referring to the Request. This may be one of: 

- Accept Response to Request to Transfer FDU (AD Service) 

Parameters: 

- request identifier 

- Virtual Channel identifier 

- Reject Response to Request to Transfer FDU (AD Service) 

Parameters: 

- request identifier 

- Virtual Channel identifier 

In response to this request the Transfer Layer signals its acceptance or rejection of the Request. 
However, if the Transfer Layer is unable to transmit the FDU immediately (for example 
because the spacecraft has indicated it cannot immediately accept any more data), then the 
Transfer Layer will delay signalling to the Higher Layer its acceptance of the FDU from the 
Higher Layer, even though it places the FDU in its Wait_Queue. The Higher Layer may not 
issue another Request to Transfer FDU until the current one has been accepted or rejected. 

Whenever it has transfer capacity after a period when there was no extra capacity available, the 
FOP-1 protocol machine looks at the AD Service interface to see if an FDU is in the 
Wait_Queue. If so, the Transfer Layer accepts the FDU, which is then deemed to be under 
control of the Transfer Layer. 

After each Accept Response to Request to Transfer FDU (AD Service), but asynchronously 
from the Response, the Transfer Layer signals to the Higher Layer a confirm response 
referring to the Request. This may be one of: 
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- Positive Confirm Response to Request to Transfer FDU (AD Service) 

Parameters: 

- request identifier 

- Virtual Channel identifier 

- Negative Confirm Response to Request to Transfer FDU (AD Service) 

Parameters: 

- request identifier 

- Virtual Channel identifier 

Because there may be a number of FDUs which have been accepted, but not confirmed, the 
two layers need to share a common system of request identifiers for use when referring to a 
particular request (and, therefore, to a particular FDU). 

The Positive Confirm Response to Request to Transfer FDU (AD Service) notifies the Higher 
Layer that the FDU was received on board and acknowledged by a CLCW. If the Transfer 
Layer is unable to guarantee that an FDU was transferred on board despite retry attempts, a 
Negative Confirm Response for that FDU is passed to the Higher Layer. 

The Negative Confirm Response to Request to Transfer FDU (AD Service) does not carry a 
parameter giving the reason for the failure to confirm the requested data transfer service. 
However whenever a condition is detected which might give rise to such responses, an Alert 
Indication is signalled from the Transfer Layer to the Higher Layer. 

From the point of view of the Higher Layer, between the time of acceptance of an FDU by the 
Transfer Layer until a positive confirm response is received, the FDU is in a "Grey Area" in 
which it is not possible to know if it has been transferred on board. FDUs for which a 
negative confirm response is received may have been unsuccessfully uplinked or they may not. 
Therefore a negative confirm response signals a break in the Sequence-Controlled Service 
guarantee. 

If an FDU has not been accepted, it is deemed to be still under the control of the Higher Layer 
and is not covered by the Sequence-Controlled Service guarantee. Once FOP-1 detects a 
problem (for example a failure of the automatic error recovery mechanism to ensure transfer on 
board) leading to a break in the Sequence-Controlled Service guarantee, it rejects the 
outstanding Request to Transfer FDU. Therefore an FDU which has not been accepted can 
never be in the "Grey Area". 

(c) Expedited Service Interface 

The Expedited Service Interface is the service access point used for FDUs to be transmitted via 
BD frames. 


Data transferred through this interface are covered by the Expedited Service guarantee to deliver 
data without error, in order, without duplication but with possible omissions (The data are not 
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duplicated because there is no automatic retransmission mechanism; the frame is transmitted 
only once). If any error recovery is required, it has to be performed by the Higher Layers. 

Only one operation is performed by the Higher Layer on this interface. This is to present an 
FDU to the Transfer Layer: 

- Request to Transfer FDU (BD Service) 

Parameters: 

-FDU 

- request identifier 

- Virtual Channel identifier 

After each request, perhaps immediately, perhaps after a delay, the Transfer Layer returns to 
the Higher Layer a Response referring to the Request. This may be one of: 

- Accept Response to Request to Transfer FDU (BD Service) 

Parameters: 

- request identifier 

- Virtual Channel identifier. 

- Reject Response to Request to Transfer FDU (BD Service) 

Parameters: 

- request identifier 

- Virtual Channel identifier. > 

As long as the sending end Lower Layers are capable of accepting the BD frame, it will be 
accepted from the Higher Layer and transmitted. If the Lower Layers cannot accept the BD 
frame, it will be rejected; there is no Wait_Queue for BD frames. 

As no error recovery is performed by COP-1 for a BD frame, a copy of the data is not kept by 
FOP-1 and no confirmation of its acceptance by the receiving end is signalled on this interface. 

3.3.2 RECEIVING END 

At the receiving end of COP-1 (i.e. FARM-1), the user data are delivered as a buffer containing 
an accepted TC FDU. No distinction is made between a TC FDU delivered by means of an AD 
frame and one delivered by a BD frame. However, the management of the FARM-1 back-end 
buffer is affected as follows: 

- BD frames 

When a frame of this type is accepted by FARM-1, the TC FDU it contains shall be placed in 
the BD back-end buffer of FARM- 1 even if this buffer still contains data (partially read out or 
not), in which case these data will be erased, an abort signal sent to the Higher Layer to signal 
the erasure and the new data signalled as "arrived". 
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- AD frames 

When a frame of this type is accepted by FARM-1, the TC FDU it contains shall be placed in 
the AD back-end buffer of FARM-1 and a signal sent to the Higher Layer only when the buffer 
is available (empty). If the buffer still contains data, the newly arrived AD frame shall be 
discarded. 


Therefore FARM-1 must always know when its back end buffers still contain data. (See also 
the related Note in Section 3.1.1, Paragraph (b).) 

All this can be expressed by the following service primitives: 

a) From FARM- 1 to Higher Layer 

- FDU Arrived Indication 
Parameters: 

-TC FDU data 

- Virtual Channel identifier 

- FDU Aborted Indication 

The Virtual Channel identifier is normally implicit. 

b) From Higher Layer to FARM- 1 

No specific service primitive is defined. Any required data flow control signalling may be 
defined, as long as the back pressure is felt by FARM-1, i.e. FARM-1 must always know 
whether its AD back end buffer is empty or not. 

No interface with the Higher Layer exists for control frames (BC); control commands are used 
only within COP-1. 


Finally, data link service anomalies may result in discontinuities in the data transfer service. 
This may or may not require erasing incomplete data in the Higher Layers. This problem is 
mentioned in Section 3.5 (Actions; Note of Paragraph 3.5.2). 

3.4 COP-1 INTERFACE TO LOWER LAYER 

3.4.1 SENDING END 

a) From FOP-1 to Frame Generation 

-Transmit Request for Frame 
Parameters: 

- Request Identifier 
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- Frame Data including: 

- Version/format identifier 

- Type identifier (AD, BD or BC) 

- Spacecraft identifier 

- Virtual Channel Identifier 

- Frame Sequence Number, N(S), for AD frames 

- Data (TC FDU or Control Command) 

- Abort Request 

Parameters: 

- Virtual Channel Identifier 

b) From Frame Generation to FOP- 1 

Each Transmit Request is acknowledged with one of two possible responses. 

- Accept Response 

Parameters: 

- Request Identifier of Transmit Request 

- Virtual Channel Identifier 


- Reject Response 
Parameters: 

- Request Identifier of Transmit Request. 

- Virtual Channel Identifier 


3.4.2 RECEIVING END 

a) From the Frame Validation Check to FARM- 1 

- Valid Frame Arrived Indication 
Parameters: 

- Frame Type (AD, BD or BC) 

- Virtual Channel Identifier 

- Frame Sequence Number, N(S), for AD frames 

- Data (TC FDU or Control Command) 

The Frame Type information is used for demultiplexing the Frame Data of different services 
(AD, BD, BC). The Virtual Channel identifier is normally implicit, since there is a separate 
FARM-1 for each Virtual Channel. Note: all of this information could be transferred by 
providing the entire frame, including the header. 
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b) From FARM- 1 to the Frame Validation Check 
- No service primitives are specified. 

3.5 ACTIONS 
3.5.1 FOP-1 


The actions related to the interface between FOP-1 and the Higher Layer have been covered in 
Section 3.3. 


The FOP-1 State Table (See Table 3.1) expresses the operations to be performed for each 
event/state combination. Description of the State Table format is included in Section 1.3. 

Because of space considerations in the table and in order to avoid repetition in the text of this 
section, certain abbreviations have been used. These are listed below: 

-^'Purging the Sent_Queue" includes clearing the Sent_Queue by generating a Negative 
Confirm response for each frame on the queue and deleting the frame. (Note: Purging the 
Sent_Queue only occurs as part of the termination of an AD Service). 

-"Purging the Wait.Queue" includes clearing the Wait.Queue and generating a Reject 
Response for the queued FDU. J 


-"Transmit", for an AD or BC Frame (i.e. for the Sequence-Controlled Service), includes all 
the functions necessary to prepare a frame for transmission. In particular it includes: 


- inserting the current value of V(S) into the N(S) field of the 
incremendng V(S) (for AD frames only) 


frame and then 


- a dding the master copy of the frame to the Sent_Queue (for AD and BC frames) with 
the To_Be_Retransmitted_Flag NOT set 

-if the Sent.Oueue was previously empty, setting the Transmission.Count to 1 (for AD 
and BC frames). 


- starting the Timer (for AD and BC frames) 


- setting the AD_Out (or BC_Out) Rag to Not_Ready 


- passing a copy of the frame (AD or BC) to the Lower Layer 
Transmit Request for (AD or BC) Frame 


as a parameter of a 
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-"Transmit", for a BD Frame (i.e. for the Expedited Service), includes all the functions 
necessary to prepare the frame for transmission. In particular it includes: 

-setting the BD_Out Flag to Not_Ready 

- passing a copy of the BD frame to the Lower layer as a parameter of a Transmit Request 
for (BD) Frame 

- "Initiate AD (or BC) Retransmission" includes: 

- passing an Abort Request to the Lower Layer 

- incrementing the Transmission Count 

- starting the Timer 

- marking all AD frames (or the BC frame) on the Sent_Queue as "To_Be_Retransmitted" 

- "Remove Acknowledged Frames from Sent_Queue" includes: 

- generating a Positive Confirm Response to Request to Transfer FDU for each 
acknowledged frame and deleting the frame 

- updating the value of NN(R) 

- setting the Transmission_Count to 1 

- "Alert" includes: 

- cancelling the Timer 

- purging the Sent_Queue 

- purging the Wait_Queue 

-completing the processing of any Initiate AD Service Directive by generating a Negative 
Confirm response for the Directive 

-generating an Alert signal to the Higher Layer 

- "Look for Directive" includes: 

-checking if the BC_Out_Flag is set to Ready. If not, no further processing can be 
performed for retransmitting the BC frame until an Accept Response is received for the 
outstanding Transmit Request for (BC) Frame, setting the BC_Out_Flag to Ready. 
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-if the BC_Out_Flag is set to Ready, checking if the BC frame on the Sent_Queue is 
flagged "To_Be_Retransmitted". If so, the flag is set to Not_Ready and a copy of the 
BC frame is passed to the Lower Layer as a parameter of a Transmit Request for (BC) 
Frame. 

- "Look for FDU” includes: 

-checking if the AD_Out_Flag is set to Ready. If not, no further processing can be 
performed for transmitting AD frames. (When an Accept Response is received for the 
outstanding Transmit Request for (AD) Frame, FOP-1 will set the AD_Out_Flag to 
Ready and execute a new "Look for FDU".) 

-if the AD_Out_Flag is set to Ready, checking if an AD frame on the Sent_Queue is 
flagged "To_Be_Retransmitted". If so, the flag is set to Not_Ready and a copy of the 
first such AD frame is passed to the Lower Layer as a parameter of a Transmit Request 
for (AD) Frame and its To_Be_Retransmitted Flag is reset. 

-if no AD frame is marked "To_Be_Retransmitted", checking if both V(S)<NN(R)+K 
and an FDU is available at the AD Service Interface on the Wait_Queue. If so, the 
FDU is removed from the Wait_Queue, an Accept Response to Request to Transfer 
FDU is passed to the Higher Layer and the "Transmit" action for AD Frame (see above) 
is performed. 

-if no FDU is available on the Wait_Queue, no further processing is performed. 

- "Initialise" includes: 

- purging the Sent_Queue 

- purging the Wait_Queue 

- setting Suspend State (SS) to 0 

"Suspend" includes: 

- generating a Suspend signal to the Higher Layer 

-"Resume" includes: 

- starting Timer 

- setting Suspend State (SS) to 0 

The State Tables show the new state value at the bottom of each box (for example "(S 1)"). 
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References to: 

- Lockout_Flag 

- Wait_Flag 

- Retransmit_Flag 
-N(R) 

pertain to the values in the current CLCW. 

The FOP-1 table is large and the state transitions complex. Therefore the newcomer may find it 
helpful to consider initially only the state changes relating to the main protocol. This is shown, 
for the normal situation in which no exception conditions occur, in Figure 3.3. This protocol 
is capable of handling automatically flow control and error control (providing the quality of the 
link is not so low that a maximum of Transmission_Limit transmissions fail to transfer a frame 
on board). It is not capable of handling improper operation of the spacecraft link, for example 
caused by two ground stations simultaneously sending Transfer Frames to the same spacecraft. 

Next consideration should be given to the initialisation protocol used, for example, to initiate 
and terminate a session using the AD Service. This is shown in Figure 3.4 and shows the 
main protocol States (SI), (S2) and (S3) coalesced into a single state. The FOP-1 State Table 
distinguishes among many events all of which should never occur. If one of these situations is 
detected, an Alert signal is passed to the Higher Layer and FOP-1 enters the Initial State (S6).' 
Except for Alert [term] after a "Terminate AD Service Directive’, all these traps are grouped 
under "Exceptions" in Figure 3.4. 

A detailed summary of the way FOP-1 moves between all states is given in Figure 3.5. 

3.5.2 FARM-1 

The actions related to the interface between FARM-1 and the Higher Layer have been covered 
in Section 3.3. 

Various abbreviations are used in the FARM-1 State Table (see Table 3.2). These are listed 
below: 

-"Valid frame arrives" means that the Frame Validation Check has placed a "valid" frame in the 
front end buffer. 

-"Accept" for an AD frame may be subject to a buffer release signal from the Higher Layers if 
the Higher Layer is implemented to take advantage of the "Wait" concept. When no AD back 
end buffer is available (Event E2), the frame must be discarded. 

-"Accept" for a BD frame means that the data contents of the frame (TC FDU) are placed in the 
back end buffer even when this buffer still contains data, in which case these previous data are 
erased. The "Wait" concept does not apply to BD frames: the FDU is deemed to have 
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unimpaired access to the Higher Layers and the necessary interfaces must be implemented to 
this effect (recovery requirements specific to the mission). 

A summary of the way FARM-1 moves between states is given in Figure 3.6. 

In Table 3.2, events E7 and E8 are concerned with the execution of, respectively, an "Unlock" 
Control Command and a "Set V(R)" Control Command. The specification of each action in 
each box is self-explanatory. The action described for event E8 in state (S3) means that the 
Control Command "Set V(R)" is not executed (FARM-1 must be "unlocked" first), but 
accounted for by means of the FARM-B Counter since it was validated as "legal" and found 
"executable". 

NOTE.The execution of an "UNLOCK" Control Command resets only FARM-1, not the 
higher layers. Some mechanism should be provided to ensure that the data management 
functions of the Higher Layers purge/reset their buffers as required for spacecraft operations. 
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Table 3.1 FOP-1 State Table (Part 1) 
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Table 3.1 FOP- 1 State Table (Pan 2) 



kllmU 
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Table 3. 1 FOP- 1 State Table (Part 3) 
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Table 3.1 FOP- 1 State Table (Pan 4) 
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Table 3.1 FOP-1 State Table (Part 5) 
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Table 3.1 FOP- 1 State Table (Part 
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Table 3.1 FOP-1 State Table (Part 7) 
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Figure 3.3 FOP-1 State Transitions: Main Protocol 
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Figure 3.5 FOP-1 State Transitions 
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Table 3.2 FARM-1 State Table (Part 1) 


State Name 


Main Feature of State 


State Number 


Event 

Conditions 
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I Number 
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1 1 
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1 1 



1 

1 

1 

1 

Valid 

1 

1 

1 

N ( S ) *V (R) | A buffer 

1 El 

1 ! 
1 1 

Accept 

Not 

1 

1 Discard 

User Data 

1 

1 is 


1 1 

frame, 

applicable 

I 

type AD 

1 

1 available 

1 

1 I 

V(R) :* 


1 

frame 

1 

1 for this 


1 1 

V (R) +1, 


1 

arrives 

1 

1 frame 

i 

t » 

Ret ransml t 


; 


1 

I 

i 

1 


1 1 

i i 

Flag :» 0 


1 


1 

1 

1 

1 


l 1 
1 1 

(SI) 


i 

t (S3) 
1 


1 

1 

1 

\ No buffer 

1 E2 

1 1 
1 1 

Discard, 

Discard 

1 

1 Discard 


1 

1 is 


1 1 

Retransmit 


1 


1 

1 available 


1 1 

Flag :» l. 


1 


1 

1 for this 


1 1 

Wait Flag 




1 

1 

I frame 

i 


1 1 

:« 1 


1 


1 

1. 

f 

t 

l { 

1 I 
1 ! 

< S 2 ) 

<S2> 

1 

1 (S3) 

1 


1 

t 

N(S)>V(R) and 

! E 3 

1 ! 
1 1 

Discard, 

Discard 

1 

1 Discard 


i 

N<S)<*(V(R)+?W-1) 


1 1 

Ret ransmit_ 


1 


1 



1 1 

Flag := 1 


1 


1 

ie 


1 1 



1 


! 

inside positive part 


1 1 



1 


t 

of sliding window 


1 1 



1 


I 

1, 

and N ( S ) <>V (R) 


1 i 
. 1 1 . 

(SI) 

(S2) 

1 (S3) 

( 


1 

1 

N ( S ) <V ( R) and 

1 E A 

1 1 
1 1 

Discard 

Discard 

1 

1 Discard 


1 

i 

N (5 ) >» ( V ( R) -NW) 


1 1 



1 


i 

1 

ie 


1 1 
1 1 



I 

1 


1 

inside negative part 


1 1 



1 


1 

1. 

of sliding window 


1 ! 

,1 1. 

(SI) 

<S2) 

1 (S3) 

1 


1* 

1 

N ( S ) > < V <R) +PW-1 ) and 

t E5 

1 1 
1 1 

Discard, 

Discard, 

1 

1 Discard 


i 

N(S) <<V(R)-NW) 


1 i 

Lockout 

Lockout^ 

1 


1 



1 1 

Flag :« 1 

Flag :» 1 



1 

ie 


1 1 



1 


1 

outside of 


1 1 



1 


1 

J. 

sliding window 


1 1 
1 1 . 

(S3) 

(S3) 

1 (S3) 

1 


OPEN 


Normal 
state to 
accept 
frames 


SI 


WAIT 


Wait_Flag 
is on 


S2 


LOCKOUT 


Lockout_ 
Flag is on 


S3 


Red Book Issue 4 


3-45 


January 1991 



CCSDS RECOMMENDATION FOR TELECOMMAND: COMMAND OPERATION PROCEDURES 


Table 3.2 FARM-1 State Table (Part 2) 


State Number 
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Figure 3.6 FARM-1 State Transitions 
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ANNEX A 

GLOSSARY OF ACRONYMS 
This Annex is part of the Recommendation. 
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ANNEX A 


GLOSSARY OF ACRONYMS 


AD, BD, BC: These abbreviations reflect the state of the "Bypass" and "Control Command" 
flags in the Transfer Frame Header: 



* Bypass Flag = 0 = A = Acceptance Check 

* Bypass Flag = 1 = B = Bypass of Acceptance Check 



* Command Control Flag = 0 = D = Data 

* Command Control Flag = 1 = C = Control 



It should be noted that only AD, BD and BC are legal: AC is an illegal combination 
since Control Commands cannot reliably use a transfer service which they are 
meant to modify. (Detailed definition of these flags is provided in Reference [3]) 


ARQ: 

Automatic Request for Retransmission 


CLCW: 

Command Link Control Word (defined in Reference [3]) 


CLTU: 

Command Link Transmission Unit (defined in Reference [2]) 


COP: 

Command Operation Procedure 


FARM: 

Frame Acceptance and Reporting Mechanism 


FDU: 

Frame Data Units, the user data to be conveyed in a single frame 


FOP: 

Frame Operation Procedure 


ID: 

Identifier 


K 

FOP_Sliding_Window_Width (FOP-1 variable) 


LLEF 

Lower Layer Interface 


N(R) 

FARM-A-Counter value (COP-O) or current observed value of FARM-l's Next 
Expected Frame Sequence Number V(R) (COP-1) from the current CLCW. 


NN(R) 

The value of N(R) from the previous CLCW on that Virtual Channel. Denoted 

Expected_Acknowledgement_Frame_Sequence_Number" by COP-1. 
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N(S) The value of the Frame Sequence Number in the Telecommand Transfer Frame 
Header. 

NW FARM_Negative_Window_Width (FARM-1 variable) 

PW FARM_Positive_Window_Width (FARM-1 variable) 

S/C: Spacecraft 

SS Suspend_State. (FOP-1 variable) 

TC: Telecommand 

TM: Telemetry 

TT Timeout_Type. (FOP- 1 variable) 

Tl_Initial The initial value to which the countdown Timer is set. (FOP-1 variable) 

VC: Virtual Channel 

V(R) Receiver_Frame_Sequence_Number. The value of N(S) expected to be seen by 
FARM-1 in the next Type AD frame on the Virtual Channel. 

V(S) Transmitter_Frame_Sequence_Number. The value of the 

Frame_Sequence_Number, N(S), to be assigned by FOP-1 to the next Type AD 
frame to be transmitted. 

W FARM_Sliding_Window_Width (FARM-1 variable) 
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